The present invention relates generally to process control systems and, more particularly, to the display of alarm conditions within a process control system.
Process control systems, like those used in chemical, petroleum or other processes, typically include one or more centralized process controllers communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process such, as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, uses this information to implement a control routine and then generates control signals which are sent over the buses or other communication lines to the field devices to control the operation of the process. Information from the field devices and the controllers is sometimes made available to one or more applications executed by the operator workstation to enable an operator to perform desired functions with respect to the process, such as viewing the current state of the process, modifying the operation of the process, etc. Some known controller/operator interface software is designed to generate and display process alarms resulting from process control operations performed by software in the controllers or other devices.
The DeltaV process control system sold by Fisher Rosemount Systems, Inc. uses function blocks located or installed in controllers or different field devices to perform control operations. The controllers and, in some cases, the field devices are capable of storing and executing one or more function blocks, each of which receives inputs from and/or provides outputs to other function blocks (either within the same device or within different devices), and performs some process control operation, such as measuring or detecting a process parameter, controlling a device or performing a control operation, like implementing a proportional-derivative-integral (PID) control routine. The different function blocks within a process control system are configured to communicate with each other (e.g., within a single device or over a bus) to form one or more process control loops, the individual operations of which can thus be spread throughout the process.
Typically, the function blocks or the devices in which these function blocks are implemented are configured to detect errors, faults or problems that occur within the process control loops or the functions being performed therein and to send a signal, such as an alarm message, to notify an operator at an operator workstation or other user interface that an undesirable condition exists within the process control system or within a control loop of the process control system. Such alarms may indicate, for example, that a function block is not communicating, has received or generated an out of range input or output, is undergoing a fault or other undesirable condition, etc. In the current alarm display systems, an application executed at, for example, an operator interface/workstation, is configured to receive messages containing process alarms related to process operation and to display these process alarms in a coherent and manageable manner to thereby enable an operator to manage alarms in some organized or logical way. Such an operator interface system is described in U.S. Pat. No. 5,768,119, entitled xe2x80x9cProcess Control System Including Alarm Priority Adjustmentxe2x80x9d which is hereby expressly incorporated by reference herein.
Known operator interface applications, such as that described in U.S. Pat. No. 5,768,119, are typically configured to enable an operator, i.e., the person overseeing the actual day-to-day operation of a process control system, to view the most critical process alarms, e.g., the alarms with the highest priority, first. Because these applications are designed with the object of providing information to a process control operator, they only display alarms associated with the functioning of the process itself. These applications are not configured to display other types of errors or alarms, such as alarms associated with malfunctioning field devices or other hardware like controllers or input/output (I/O) devices. Thus, for example, in the system described in U.S. Pat. No. 5,768,119, an operator display application displays a section of a process control system and provides an alarm banner on the bottom of the display indicating the highest priority process alarms. The displayed alarms are process alarms because they are generated by function blocks or other software used to implement a process control scheme or a process control loop and to indicate an error in the functioning of a process control loop. When an operator selects one of the process alarms at the operator workstation, the application provides the operator more information related to the selected alarm, such as the function block or module which generated the alarm, the priority of the alarm, whether the alarm has been acknowledged, etc. and may display information about the process relevant to the alarm, such as a faceplate for the loop in which the alarm occurred, a primary control display related to the portion of the plant in which the alarm occurred, etc.
Using these known displays, an operator can recognize the existence of an alarm and can try to fix the problem using other software applications available to the operator. In some cases, the operator may determine, based on the process alarms present, that one or more field devices or other hardware components may need repair or replacement. If this is the case, the operator may call or otherwise contact a maintenance person to schedule the device for testing, repair or replacement. Similarly, the operator may call an engineer to handle the alarm. In this manner, the operator detects a device or hardware problem based on received process alarms and manually hands the problem off to maintenance or engineer personnel to correct the problem. However, it requires an experienced or knowledgeable operator to detect device or hardware problems from process alarms.
In the past, conventional field devices were used in process control systems to send and receive analog (e.g., 4 to 20 milliamp) signals to and from the process controller via an analog bus or analog lines. However, these 4 to 20 ma signals are limited in nature in that they are indicative of process measurements made by the device or of process control signals generated by the controller required to control the operation of the device during runtime. As a result, the conventional 4-20 ma devices are incapable of generating alarms pertaining to the operational capability of the device itself. As a result, alarms associated with these devices have generally not been available within process control systems. However, in the past decade or so, smart field devices including a microprocessor and a memory have become prevalent in the process control industry. A number of standard and open smart device communication protocols such as the Foundation(trademark) Fieldbus (hereinafter xe2x80x9cFieldbusxe2x80x9d), HART(copyright), PROFIBUS(copyright), WORLDFIP(copyright), Device-Net(copyright), and CAN protocols, have been developed to enable smart field devices made by different manufacturers to be used together within the same process control network. In addition to performing a primary function within the process, smart field devices may store data pertaining to the device, communicate with the controller and/or other devices in a digital or combined digital and analog format, and perform secondary tasks such as self-calibration, identification, diagnostics, etc. Importantly, the devices conforming to at least some of these protocols are capable of detecting problems within the device itself and of generating and sending alarms or alerts to indicate the detected problems to the appropriate operator, maintenance or engineer personnel associated with the process control system.
However, there has been few if any display applications for displaying non-process alarms, such as alarms generated by the field devices or controllers indicating some problem with the hardware associated with those devices has occurred. It is believed that there are no known displays which enable maintenance or engineer personnel to detect and attend to faulty field devices, controllers, I/O devices, etc. in a coherent or consistent manner, as there are with operator displays that display process alarms. In fact, engineers and technical personnel generally have to review numerous log printouts or stored files for alarms or other events detected about or by field devices or other hardware devices. This process is time consuming and difficult. The capability of enabling the engineer or maintenance person to view device and hardware alarms in a coherent manner is even more desirable with the advent of newer smart field devices, controllers and I/O devices which, as indicated above, are being provided with the ability to detect numerous operating problems about the devices themselves, such as when the device stops communicating, or some other problem that prevents the device from operating correctly. For example, a valve may have sensors on board that detect an overpressure or an underpressure condition, a stuck valve plug, etc. and software within the device may generate an alarm indicating the type of detected problem as well as the severity of the problem. In some cases, the problem may be critical and may need immediate attention, such as with a stuck valve plug, whereas other conditions may call for scheduling maintenance at some time in the future. For example, a valve may measure aggregate valve travel since the last maintenance and, when the aggregate valve travel reaches a predetermined threshold, may generate an alarm calling for maintenance.
Still further, in some smaller process environments, a single person may want to perform the functions of an operator, a maintenance person and an engineer. Alternatively, the operator may wish to know about problems occurring in field devices, controllers and I/O devices, because it may help him or her to make sense of some of the process alarms that appear on the traditional operator interface. In the past, there has been no easy way of enabling a single person to view all of the alarm data in an organized and integrated manner. Still further, an operator may wish to view all categories of alarms unless too much information is being displayed on the interface, at which time the operator may wish to turn certain categories of alarms off or hand the responsibility for certain alarms to someone else. Currently, there is no system which enables a single person to perform these functions.
An alarm display and interface system for use in a process control network receives and displays different categories of alarms, including for example, device alarms and hardware alarms as well as traditional process alarms, on a single display in an integrated manner to enable an operator or other user to view, have access to and manipulate the alarms of different categories. The display and interface system may be used to filter the alarms that are displayed according to any number of parameters, including category, type, priority, status, time, etc. so as to alternatively segregate or combine the tasks typically associated with operator, maintenance and engineer personnel. The alarm display and interface system may also be used to access each of the displayed alarms to obtain more information about any individual alarm.
According to one aspect of the present invention, an alarm display system is capable of being used in a process control network having a user interface with a display mechanism and a multiplicity of communicatively interconnected devices adapted to generate and send alarm messages containing alarms of various categories to the user interface. The alarm display system includes an alarm receiver configured to receive the alarm messages from the multiplicity of devices to obtain a plurality of alarms of various categories, an alarm processing unit that processes the plurality of alarms for display based on a predetermined criterion to ascertain a set of alarms for display and an alarm display unit that presents indications of the set of the alarms for display on the display mechanism, wherein the alarm display unit presents the indications of alarms of various categories in an integrated manner on the display mechanism. If desired, the alarm processing unit may include an alarm filter that filters the plurality of alarms for display based on the predetermined criterion, such as alarm category or alarm priority, to ascertain the set of alarms for display.